REMARKS 

The Examiner is thanked for the thorough examination of the present application. 
The FINAL Office Action, however, rejected claims 1-4 and 6-32 are rejected under 35 
U.S.C. 103(a) as allegedly being anticipated by Bell Labs technical Journal, Volume 8, 
Issue 1 , Pages 27-42 in view of Mayer (USP 2005/0015499). Applicant continues to 
disagree with these rejections for the reasons set out in the response filed June 18, 
2008. Notwithstanding, Applicant has amended independent claims 1 and 17 to further 
define over the cited art. For at least the following additional reasons (in addition to the 
reasons previously set forth), Applicant requests reconsideration and withdrawal of the 
rejections. 

As noted above, independent claims 1 and 17 are amended to further define the 
claims, and each amended claim specifies that "the SIP response message is a final 
response with a response code greater than 199." This feature is not disclosed in the 
citied art and renders the rejections moot. 

In addition, as amended herein, independent claims 1 and 17 respectively recite: 

1 . A triggering method for IP multimedia service control, 
comprising the steps of: 

recording a Session Initial Protocol (SIP) request message 

received by a Serving Call Session Control Function (S- 

CSCF); 

the S-CSCF receiving a SIP response message associated to 
the SIP request message; 

the S-CSCF examining the SIP response message according to a 
set of response Filter Criteria (rFC), comprising specific 
responses triggering individual application services 
available from a service provider; and 

re-issuing the SIP request message to an application server 
designated by the rFC if the SIP response message 
matches Service Point Triggers (SPTs) of one of the rFC; 
wherein the SIP response message is a final response 
with a response code greater than 199. 
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17. An Internet Protocol (IP) multimedia subsystem, comprising: 
one or more application servers each designated by a 
response Filter Criteria (rFC) to provide a service; and 

a Serving Call Session Control Function (S-CSCF), receiving a 
Session Initial Protocol (SIP) response message associated to a SIP 
request message, examining the SIP response message by a set of 
response Filter Criteria (rFC), and re-issuing the SIP request message 
to an application server when a Service Point Trigger (SPT) in a rFC 
that designates to the application server is matched by the SIP 
response message; wherein the SIP response message is a final 
response with a response code greater than 199. 

(Emphasis added). Independent claims 1 and 17 patently define over the cited art for at 

least the reasons that the cited art fails to disclose the features emphasized above. 

The amended claim 1 defines the following four fundamental steps: 

1 . the S-CSCF receives and records a (A) SIP request message; 

2. the S-CSCF receives a (B) SIP response message associated to the (A) SIP 
request message; 

3. the S-CSCF examines the (B) SIP response message according to a set of 

response Filter Criteria (rFC); and 

4. if the (B) matches a SPT in a rFC, the S-CSCF re-issues the (A) to an 
application server designated by the rFC. 



As embodied in the amendment, the SIP response message is a final response 
with a response code greater than 199. Support for this feature is provided in page 8, 
lines 24-26. In this regard, the "486 busy here" in the embodiment of Fig. 4b is the SIP 
response message. A more detailed definition can be found in IETF RFC 3261 Sect. 21 
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(pp. 182-193), which is also readily available from the Internet and can be found through 
search engines like Google. 

In maintaining the previous rejections, the Advisory Action has misinterpreted the 
claims. In this regard, the Advisory Action states that SIP INVITE is an SIP response 
message. More specifically, the Advisory Action states that the "Bell Labs Technical 
Journal discloses that in Fig. 9, the S-CSCF forwards the SIP INVITE (SIP response 
message) to the CF application server based on the filter criteria retrieved from the HSS 
when the filter criteria matches for the AS (step 8), column 2, page 40, lines 2-4." The 
SIP INVITE, however, is an SIP request message and not an SIP response message 
(and there is a fundamental difference between the two message types). 

In this regard, the present application described such an invite message (see 
e.g., specification paragraphs bridging pages 7-8.). As an example, the specification 



As shown in Figure 4a, the originating user equipment (UE1 ) 201 
originates an SIP invite message according to the standard 3GPP IMS 
to request a call establishmentw\th the terminating user equipment 
(UE2) 235. The SIP invite message passes from UE1 201 to the P- 
CSCF 205 and S-CSCF 211 of UE1 's home network 21 , then further 
passes to the l-CSCF 221 and HSS 222 of UE2's home network 22. 
HSS 222 then sends back the location information of the UE2 235 to the 
l-CSCF 221 , so the l-CSCF 221 is able to pass the SIP invite message 
to the S-CSCF 223 of UE2's home network 22. The S-CSCF 223 
checks the SIP invite message with the iFC, and forwards the SIP invite 
message to an application server (AS) 224a once the SIP invite 
message matches the iFC. Accordingly, the AS 224a tries to establish a 
call to UE2 235 via the S-CSCF 223 and P-CSCF 231 . Unfortunately, 
UE2 235 is busy at the moment, thus it responds an SIP response 
message of "486 busy here" to the AS 224a via the same path. The 
AS 224a establishes a call to a Voice Mail (VM) server 224b if the user 
profile of UE2 235 includes a voice mail service. The VM server 224b 
replies an SIP response message of "200 OK" to the AS 224a to agree 
the call setup between UE1 201 and the VM server 224b. Notice that 
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the VM server 224b is also an application server, but it is a terminating 
application rather than a back-to-back application server. 

From this teaching, and as will also appreciated by persons skilled in the art, the SIP 
INVITE message (which is actually an SIP request message) is fundamentally different 
from the claimed SIP response message. For at least this reason, the rejections should 
be withdrawn. 

In addition, the Advisory Action also states: "Further, Bell Labs Technical Journal 
fails to specifically teach SIP response message received by S-CSCF according filter 
criteria. However, Mayer teaches SIP request received is forwarded to S-CSCF and S- 
CSCF responds to SIP request per the event filter, page 3, lines 1 0-1 7." Applicant 
respectfully disagrees with this application of the art, as Mayer does not appear to teach 
anything like "re-issuing the SIP request message to an application server designated 
by the rFC if the SIP response message matches Service Point Triggers (SPTs) of one 
of the rFC," as expressly recited in claim 1. Therefore, even if Mayer could be properly 
combined with the Bell Labs Technical Journal article, the resulting combination still fails 
to disclose the features of the claimed embodiments. For at least this additional reason, 
the rejection of claim 1 should be withdrawn. 

Further still, the Advisory Action states: "Mayer discloses examining a 
corresponding SIP response message received by the S-CSCF according to a set of 
response Filter Criteria (rFC) (SIP request received is forwarded to S-CSCF (Fig. 2, 21 , 
22, paragraph [0025], page 3, lines 10-15) and S-CSCF responds to SIP request per 
the event filter, Fig. 2, 23, paragraph [0025], lines 15-17)". In this regard, it appears that 
the Office Action has interpreted the "SIP SUBSCRIBE request" of Mayer has being the 
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SIP request message, and has interpreted step 23 of Fig. 2 as being the SIP response 
message. However, with this interpretation, the fundamental operation of Mayer would 
be different than that defined in claim 1 . In Claim 1 , the S-CSCF receives an SIP 
response message associated with the SIP request message, and re-issues an SIP 
request message to somewhere according to something matched by the SIP response 
message . In Mayer's Fig. 2 step 23, the S-CSCF responds to the SIP request per the 
event filter by sending an SIP request to somewhere else (local service configuration 
server 17). Mayer never discusses or suggests an operation dependent on an SIP 
response message. For at least this additional reason, the rejection of claim 1 should 
be withdrawn. 

For at least the foregoing several reasons, Applicant respectfully requests 
reconsideration and withdrawal of the rejection of claim 1 . As independent claim 17 
embodies similar defining features, the rejection of claim 17 should be withdrawn for the 
same reasons. Insofar as all remaining claims depend from either claim 1 or claim 17, 
all rejections should be withdrawn. In re Fine, 837 F.2d 1071, 5 U.S.P.Q.2d 1596, 1600 
(Fed. Cir. 1988). 

Should the Examiner believe that a teleconference would be helpful to expedite 
the examination of this application, the Examiner is invited to contact the undersigned. 
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A credit card authorization is provided herewith to cover the fee associated with the 

accompanying RCE application. No additional fee is believed to be due in connection with 

this amendment and response. If, however, any additional fee is deemed to be payable, 

you are hereby authorized to charge any such fee to Deposit Account No. 20-0778. 

Respectfully submitted, 

/Daniel R. McClure/ 

By: 

Daniel R. McClure, Reg. No. 38,962 

Thomas, Kayden, Horstemeyer & Risley, LLP 

600 Galleria Pkwy, SE 
Suite 1500 
Atlanta, GA 30339 
770-933-9500 
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